Como validar headers y query params en AWS API Gateway

API Gateway provee un sistema básico para validar los query parameters (parámetros de consulta) y los headers (encabezados) de tu petición.
Primero lo primero, necesitas una API con una Lambda. En caso de que quieras aprender como hacer una en AWS desde 0, puedes revisar Como crear una REST API con Lambda en AWS en 6 pasos.

Una vez puedas llamar a una Lambda con tu API, puedes volver y continuar con los siguientes pasos.


En este ejemplo tengo una API llamada SampleAPI y un recurso llamado sample con un método GET.

Para empezar debes acceder a la sección de Solicitud de método del método GET del recurso en cuestión.

Captura de pantalla mostrando el recurso /sample creado con un método GET en una API llamada SampleAPI.

En esta sección como el nombre lo indica puedes configurar los requerimientos para llamar al método. Esto incluye opciones de autorización y de validación del body (cuerpo), headers y query params. Como ya sabes por el momento nos enfocaremos en los últimos 2.

Query Parameters (Parametros de consulta)

Los query params son parámetros en las URL que tienen asociado algun valor.

Un ejemplo sería algo así:

https://example.com/cars?color=red&type=small

Esta URL tiene 2 query params:

Query Param (Parámetro de Consulta)Valor
colorred
typesmall

Como te imaginarás esto sirve para pasarle valores al back-end y que se pueda filtrar o procesar la información en base a estos parámetros.


Volviendo a API Gateway. Ahora haz clic en “Parámetros de cadenas de consulta de URL” y agrega una cadena de consulta.

Captura de pantalla remarcando el botón de "Agregar cadena de consulta" demtro de la sección de "Párametros de cadena de consulta de URL". Estas opciones se muestran en el panel de "Solicitud de método" en el método GET.

En este ejemplo agregaré 3 parámetros y marcaré 2 como obligatorios:

Captura de pantalla mostrando los parámetros creados dentro de la sección de "Párametros de cadenas de consulta de URL".
Los parámetros obligatorios son: name y type. El parámetro sort no esta marcado como obligatorio.

* Seguramente habrás notado la columna de Almacenamiento en caché. Esta opción sirve para precisamente guardar en caché el resultado de un request, mejorando su velocidad de respuesta en futuras llamadas durante un cierto periodo de tiempo.

AWS mostrará la siguiente advertencia en la columna “Obligatorio”

Captura de pantalla mostrando una advertencia de que no hay validador configurado para parámetros obligatorios.

Para solucionarlo hay que hacer precisamente lo que AWS indica. Configura la opción de Validador de Solicitudes de la siguiente manera:

Captura de pantalla remarcando la opción de "Validar parámetros de cadena de consulta y encabezados" asignada a la propiedad de "Validador de solicitudes" dentro de la sección de Configuración del panel de "Solicitud de método" del método GET.

Si no habilitas esto API Gateway no validará nada aunque lo hayas configurado en las otras secciones.

Una vez tienes configurados los parámetros que quieres que sean obligatorios debes implementar el API para poder probarlo.

*Recuerda que para implementar tu API, debes seleccionar Acciones->Implementar la API

Probando la validación de parámetros

Veamos como se comporta nuestro API con los nuevos cambios.

*Para hacer las pruebas te recomiendo utilizar un cliente como Postman o Insomnia. Si como yo usas VsCode te recomiendo el plugin de ThunderClient.

Al hacer una llamada con todos los parámetros verás que efectivamente la petición funciona correctamente:

Captura de pantalla mostrando una llamada GET al URL del recurso /sample creado anteriormente. La petición se hace con los parámetros: name=Tom, type=human. La respuesta es éxitosa regresando un arreglo en el body de la respuesta y un código 200.

Sin embargo si haces una llamada sin ningun parámetro API Gateway devolverá un error:

Captura de pantalla mostrando una llamada GET al URL del recurso /sample creado anteriormente. La petición se hace sin incluir ningun parámetro.. La respuesta es fallida, regresando un error con el código "400 Bad Request" y con el mensaje "Missing required request parameters: [name, type]".

Precisamente ese es el comportamiento que esperabamos. Como ya te habrás dado cuenta el parámetro que no se marcó como obligatorio es irrelevante. No importa si lo pasas o no en la llamada.

Headers (Encabezados)

Los headers son otra forma de recibir valores de un request. Usualmente se usan para almacenar meta-datos acerca de la petición.

Por lo general se utilizan para guardar información acerca de autorización, cookies, cache o del formato de respuesta esperado. Sin embargo nada te impide usarlos para pasar algún dato adicional que tu quieras. A diferencia de los query params estos valores no son visibles en la URL.

Para configurar los headers dirígete a la misma sección en donde configuraste los query params y selecciona la opción de “Encabezados de solicitud HTTP”.

En mi caso hice lo mismo que con los query params y también agregué 3 headers, marcando 2 como obligatorios:

Captura de pantalla mostrando los headers creados dentro de la sección de "Encabezados de solicitud de HTTP" dentro del panel de "Solicitud de método" en el método GET del recurso /sample.
Los headers creados son 2. appID y customKey marcados como obligatorios y keyDate no marcado como obligatorio.

Dado que haz modificado el API necesitas volver a mandar a llamar la opción de Implementar la API, para que los cambios se reflejen en la versión publicada.

Aseguraté de que la Etapa que hayas creado este usando la última implementación que hayas agregado.

*Es de extrema utilidad poner una buena descripción al momento de Implementar la API para que puedas encontrar la implementación correcta en el listado.

Captura de pantalla mostrando el listado de implementaciones en la pestaña de "Historial de implementaciones" de la etapa de "dev" en sección de "Etapas".
La etap seleccionada como Etapa Actual muestra la etapa con descripción "Headers".

Si mandas a llamar el endpoint con los mismos parámetros que la vez anterior ahora obtendrás un error:

Captura de pantalla mostrando una llamada al API con los parámetros name y type incluidos pero regresando error 400 Bad Request.
El error contiene el mensaje "Missing required request parameters: [customKey, appId]".

Si te fijas el error es el mismo que arroja AWS cuando no agregas los query params necesarios. No te dejes engañar, el API mostrará el mismo error aunque añadas las llaves que te indica en los query parameters:

Captura de pantalla mostrando una llamada al API con los parámetros name, type y customKey  incluidos pero regresando error 400 Bad Request.
El error contiene el mensaje "Missing required request parameters: [customKey, appId]".

A pesar de que el error no especifíque en donde deben colocarse los parámetros que faltan tu sabes que hacen falta en los headers. Al agregarlos y realizar nuevamente la llamada, obtendrás una petición exitosa.

*Thunder Client agrega automáticamente los 2 primeros headers al request. No es necesario que los agregues.

Captura de pantalla mostrando una llamada al API con los headers Accept, User-Agent, customKey y appID. La llamada es exitosa  y regresa un arreglo en el body de la respuesta con un código 200.

Listo haz aprendido a validar headers y query params obligatorios en tu API. API Gateway se encarga de hacer esta validación por ti y ni siquiera se molesta en llamar a la Lambda si la petición no cubre los requisitos mínimos que le indiques.

Evidentemente hay validaciones más complejas que podrías hacer como requerir forzosamente 1 de 2 parámetros o permitir solo valores numéricos. Para esta clase de validaciones si necesitarás procesar la información y por ende es más común que se haga dentro de tu función Lambda.